C++ 환경에서의 WebTransport

1. 서론

현대의 웹 애플리케이션은 정적인 정보 제공을 넘어, 실시간 상호작용을 기반으로 하는 동적인 경험을 제공하는 방향으로 진화하고 있다. 이러한 변화의 중심에는 클라이언트와 서버 간의 지속적이고 효율적인 양방향 통신 기술이 자리 잡고 있다. 전통적인 HTTP 요청-응답 모델은 이러한 요구사항을 충족시키기에 근본적인 한계를 가졌으며, 이를 극복하기 위해 WebSocket과 WebRTC 같은 기술들이 등장했다.1

WebSocket은 HTTP 연결을 통해 전이중(full-duplex) 통신 채널을 제공함으로써 실시간 메시징의 문을 열었으나, 그 기반이 되는 TCP(Transmission Control Protocol)의 고질적인 문제인 HOL(Head-of-Line) 블로킹과 단일 스트림의 제약에서 자유롭지 못했다.3 한편, WebRTC는 브라우저 간 P2P(Peer-to-Peer) 미디어 및 데이터 통신에 혁신을 가져왔지만, 클라이언트-서버 아키텍처에서는 ICE(Interactive Connectivity Establishment), STUN(Session Traversal Utilities for NAT), TURN(Traversal Using Relays around NAT) 등 복잡한 프로토콜 스택으로 인해 서버 구축과 유지보수가 매우 까다롭다는 단점을 안고 있었다.5

이러한 기존 기술들의 명백한 간극을 메우고, 더 빠르고 유연하며 효율적인 웹 통신을 구현하기 위해 IETF(Internet Engineering Task Force)와 W3C(World Wide Web Consortium)의 협력 하에 WebTransport가 탄생했다.1 WebTransport는 단순한 API가 아니라, 차세대 인터넷 프로토콜인 HTTP/3와 그 근간을 이루는 QUIC(Quick UDP Internet Connections) 위에 구축된 새로운 프로토콜 프레임워크다.8 이를 통해 QUIC이 제공하는 낮은 연결 지연, HOL 블로킹 해결, 향상된 혼잡 제어, 원활한 연결 마이그레이션과 같은 강력한 이점들을 웹 애플리케이션이 직접 활용할 수 있는 길을 열었다.3

본 안내서는 C++ 개발자와 시스템 아키텍트의 관점에서 WebTransport의 기술적 본질을 심층적으로 탐구하는 것을 목표로 한다. 제1장에서는 WebTransport의 기반이 되는 QUIC과 HTTP/3 프로토콜의 핵심 원리를 분석하고, 제2장에서는 IETF 표준에 명시된 WebTransport의 핵심 기능인 스트림과 데이터그램을 상세히 다룬다. 제3장에서는 WebSocket 및 WebRTC 데이터 채널과의 다각적인 비교를 통해 WebTransport의 기술적 포지셔닝을 명확히 한다. 제4장에서는 본 안내서의 핵심인 C++ 환경에서의 구현 전략을 논하며, 현재 C++ 생태계의 현황을 진단하고, 구체적인 라이브러리 사례 연구와 구현 접근법을 제시한다. 제5장에서는 실시간 게임, 저지연 스트리밍 등 주요 활용 사례를 분석하고 성능 고려사항을 도출한다. 마지막으로, 결론에서는 C++ 환경에서 WebTransport를 도입하려는 개발자들을 위한 종합적인 제언을 제시한다.

2. WebTransport 프로토콜의 기술적 기반

WebTransport의 강력함은 그 기반 기술인 QUIC과 HTTP/3에서 비롯된다. 이 프로토콜들을 이해하는 것은 WebTransport의 동작 방식과 그 잠재력을 온전히 파악하기 위한 필수적인 선행 과정이다.

2.1 QUIC: TCP의 한계 극복

QUIC은 구글에 의해 설계되어 IETF에서 표준화된 차세대 전송 계층 프로토콜로, 웹의 성능 저하 요인으로 지목되어 온 TCP의 근본적인 한계를 해결하는 데 초점을 맞추고 있다.3

2.1.1 Head-of-Line 블로킹 해결

전통적인 TCP 기반의 통신에서 가장 큰 성능 저하 요인 중 하나는 HOL(Head-of-Line) 블로킹이다. TCP는 단일 바이트 스트림 내에서 패킷의 순서를 엄격하게 보장하기 때문에, 만약 하나의 패킷이 네트워크 상에서 유실되거나 지연되면 그 패킷이 재전송되어 도착할 때까지 후속 패킷들은 모두 전송이 막히고 대기해야 한다.2 HTTP/2는 애플리케이션 계층에서 여러 요청과 응답을 스트림으로 다중화(multiplexing)하여 이 문제를 일부 완화했지만, 전송 계층인 TCP 자체의 HOL 블로킹은 해결하지 못했다. 결국, 여러 HTTP/2 스트림 중 하나의 스트림에서 패킷 유실이 발생하면, 다른 모든 스트림까지 영향을 받는 문제가 여전히 존재했다.3

QUIC은 이 문제를 근본적으로 해결하기 위해 UDP(User Datagram Protocol) 위에 구축되었다. QUIC은 전송 계층 자체에서 다수의 독립적인 논리적 스트림을 다중화한다.10 각 스트림은 독립적인 흐름 제어와 순서 번호를 가지므로, 특정 스트림에서 패킷 유실이 발생하더라도 다른 스트림의 데이터 전송에는 전혀 영향을 미치지 않는다.3 이는 마치 여러 개의 독립된 TCP 연결을 사용하는 것과 유사한 효과를 내지만, 단일 UDP 연결 위에서 동작하므로 훨씬 효율적이다.

2.1.2 연결 설정 최적화

TCP 연결은 3-way 핸드셰이크 과정을 거치며, 보안을 위해 TLS(Transport Layer Security) 핸드셰이크가 추가로 필요하다. 이 과정은 여러 번의 RTT(Round-Trip Time)를 소모하여 연결 지연을 유발한다. QUIC은 전송 계층 핸드셰이크와 암호화 계층 핸드셰이크(TLS 1.3 기반)를 통합하여 이 과정을 최적화했다.3 최초 연결 시 단 1-RTT만으로 암호화된 연결을 수립할 수 있으며, 한 번 연결했던 서버에 다시 접속할 때는 0-RTT 연결 재개를 통해 데이터를 즉시 전송할 수 있어 지연 시간을 획기적으로 단축시킨다.13

2.2 HTTP/3: QUIC 기반의 차세대 HTTP

HTTP/3는 HTTP의 의미(semantics) 체계, 즉 요청 메서드, 상태 코드, 헤더 필드 등은 기존 버전과 동일하게 유지하면서, 하부 전송 프로토콜을 TCP에서 QUIC으로 교체한 HTTP의 세 번째 주요 버전이다.10 RFC 9114로 표준화된 HTTP/3는 QUIC이 제공하는 스트림 다중화, 저지연 연결 설정, 향상된 혼잡 제어 등의 기능을 그대로 활용하여 웹페이지 로딩 속도와 전반적인 통신 성능을 크게 향상시킨다.10

2.3 WebTransport와 HTTP/3의 통합

WebTransport는 독립적인 프로토콜이 아니라, 기존의 HTTP/3 인프라 위에서 동작하도록 설계되었다. 이는 방화벽 통과, 서버 관리 등에서 큰 이점을 제공하며, 이 통합의 핵심에는 HTTP CONNECT 메서드의 확장된 활용이 있다.

2.3.1 CONNECT 메서드를 통한 세션 수립

WebTransport 세션은 HTTP/3 연결 위에서 확장된 CONNECT 메서드를 사용하여 시작된다.8 클라이언트는 특정 경로에 대해 CONNECT 요청을 보내고, 헤더에 WebTransport를 사용하겠다는 의사를 표시한다. 서버가 이를 수락하면, 해당 HTTP/3 연결 내에 새로운 WebTransport 세션이 생성된다. 이 메커니즘을 통해 일반적인 HTTP 트래픽(웹페이지, API 요청 등)과 WebTransport 실시간 트래픽이 동일한 QUIC 연결과 포트(일반적으로 443)를 공유하면서도 논리적으로는 완벽하게 분리된 통신 채널을 운영할 수 있게 된다.8

2.3.2 CONNECT 메서드의 역할 재정의: 네임스페이스 예약 메커니즘

WebTransport에서 CONNECT 메서드의 역할은 기존의 HTTP 프록시 터널링을 위한 용도를 넘어선다. 이는 QUIC이라는 범용 다중 스트림 전송 프로토콜 위에서, 특정 스트림들의 집합에 대한 ’네임스페이스(namespace)’를 예약하고 소유권을 선언하는 정교한 메커니즘으로 작동한다. 이 과정은 다음과 같이 이해할 수 있다.

1. QUIC은 그 자체로 다수의 스트림을 제공하는 범용 전송 프로토콜이다.10
2. HTTP/3는 이 스트림들을 활용하여 HTTP 요청과 응답을 처리한다.15
3. WebTransport는 동일한 QUIC 연결을 사용하면서도, HTTP와는 다른 애플리케이션 정의 프로토콜을 위한 별도의 스트림들을 필요로 한다.8
4. 이때, 어떤 스트림이 HTTP용이고 어떤 스트림이 특정 WebTransport 세션용인지 명확하게 구분할 방법이 필요하다.
5. IETF 표준(draft-ietf-webtrans-http3)은 이 문제를 해결하기 위해 CONNECT 요청을 통해 WebTransport ’세션’을 생성하고, 이 세션에 고유한 ’세션 ID’를 부여하는 방식을 정의했다.16
6. 이후 해당 세션에 속하는 모든 WebTransport 스트림(양방향 또는 단방향)은 데이터의 시작 부분에 이 세션 ID를 변수 길이 정수(variable-length integer)로 인코딩하여 포함시킨다.16
7. 이를 통해 서버의 디멀티플렉서(demultiplexer)는 수신된 스트림의 첫 부분을 읽고 세션 ID를 파악하여, 해당 스트림을 올바른 WebTransport 세션 핸들러로 라우팅할 수 있다.

결론적으로, CONNECT 메서드는 WebTransport가 HTTP/3라는 ‘호스트’ 프로토콜 위에서 공존하는 ‘게스트’ 프로토콜로서 자신의 독립적인 통신 영역을 확보하는 공식적인 진입점 역할을 한다. 이 아키텍처는 서버가 단일 포트에서 웹페이지 서빙, REST API, 그리고 여러 개의 독립적인 실시간 데이터 통신 세션을 동시에 처리할 수 있게 하는 매우 효율적이고 확장 가능한 구조를 가능하게 한다. 이는 C++로 고성능 서버를 설계할 때, 소켓 관리 및 프로토콜 파싱 로직에 직접적인 영향을 미치는 중요한 설계 원칙이다.

3. WebTransport의 핵심 기능 분석

WebTransport는 두 가지 핵심적인 데이터 전송 프리미티브(primitive)를 제공한다: 신뢰성 있는 스트림과 비신뢰성 데이터그램. 이 두 가지를 조합하여 개발자는 애플리케이션의 요구사항에 맞춰 통신 방식을 유연하게 선택할 수 있다.

3.1 신뢰성 있는 스트림 (Reliable Streams)

스트림은 바이트 시퀀스가 순서대로, 데이터 유실 없이 안정적으로 전달되는 것을 보장하는 통신 채널이다.17 이는 TCP 연결의 동작 방식과 유사하지만, QUIC 기반으로 동작하기 때문에 여러 스트림을 생성하고 해제하는 데 따르는 오버헤드가 훨씬 적다는 장점이 있다.3

3.1.1 양방향 및 단방향 스트림

WebTransport는 두 가지 종류의 스트림을 지원한다.

• 양방향 스트림 (Bidirectional Streams): 클라이언트와 서버가 양쪽 방향으로 데이터를 읽고 쓸 수 있는 스트림이다. 클라이언트가 시작하는 모든 양방향 스트림은 HTTP/3에서 요청 스트림으로 예약되어 있으므로, WebTransport는 이를 확장하여 사용한다. 클라이언트가 WebTransport 양방향 스트림을 시작할 때는 스트림의 가장 첫 부분에 시그널 값 0x41을 보내고, 그 뒤에 세션 ID를 인코딩하여 보낸다. 이를 통해 서버는 이 스트림이 일반 HTTP 요청이 아닌 WebTransport 스트림임을 인지할 수 있다.16
• 단방향 스트림 (Unidirectional Streams): 한쪽에서만 데이터를 보내고 다른 쪽에서는 받기만 하는 스트림이다. 클라이언트 또는 서버가 시작할 수 있다. IETF 표준에 따르면, WebTransport 단방향 스트림은 스트림 타입 0x54로 식별되며, 그 뒤에 세션 ID가 따라온다.16

3.1.2 스트림 API

W3C에서 정의한 WebTransport API는 자바스크립트의 Streams API와 완벽하게 통합되어 직관적인 사용성을 제공한다.

• transport.createBidirectionalStream(): 새로운 양방향 스트림을 생성한다. 이 메서드는 Promise를 반환하며, 이행되면 WebTransportBidirectionalStream 객체를 얻을 수 있다. 이 객체는 데이터를 읽기 위한 ReadableStream과 쓰기를 위한 WritableStream 속성을 포함한다.9
• transport.createUnidirectionalStream(): 새로운 단방향 스트림을 생성한다. 이 메서드는 WritableStream을 포함하는 Promise를 반환하여 데이터를 서버로 보낼 수 있게 한다.9
• transport.incomingBidirectionalStreams 및 transport.incomingUnidirectionalStreams: 서버가 시작한 스트림을 수신하기 위한 ReadableStream이다. 이 스트림들을 통해 들어오는 각 스트림 객체를 비동기적으로 처리할 수 있다.18

3.2 비신뢰성 데이터그램 (Unreliable Datagrams)

데이터그램은 전송이나 순서가 보장되지 않는 작은 데이터 패킷을 전송하는 메커니즘이다.6 이는 UDP의 동작 방식과 매우 유사하지만, 단순한 UDP 소켓 API와는 중요한 차이점이 있다. WebTransport 데이터그램은 QUIC 계층을 통과하므로 모든 데이터가 기본적으로 암호화되며, 네트워크 혼잡을 피하기 위한 혼잡 제어의 대상이 된다.3

이러한 특성 때문에 데이터그램은 지연 시간에 극도로 민감한 데이터를 전송하는 데 이상적이다. 예를 들어, 온라인 게임에서 플레이어의 실시간 위치 정보나, 화상 통화에서 최신 음성 패킷 등이 해당된다. 일부 패킷이 유실되더라도 최신 데이터가 이전 데이터를 대체하는 시나리오에서 매우 유용하다.6 데이터그램의 크기는 기본적으로 경로 MTU(Maximum Transmission Unit)에 의해 제한된다.20

API 측면에서는 WebTransport 객체의 datagrams 속성을 통해 접근할 수 있다. 이 속성은 데이터그램을 보내기 위한 writable 스트림과 받기 위한 readable 스트림을 제공하는 WebTransportDatagramDuplexStream 객체를 반환한다.22

3.3 세션 관리 및 생명주기

WebTransport 통신은 ’세션(Session)’이라는 단위로 관리된다. 세션은 클라이언트와 서버 간의 단일 통신 컨텍스트를 의미하며, 하나의 QUIC 연결 위에 여러 개의 독립적인 세션이 동시에 존재하며 다중화될 수 있다.17

세션의 생명주기는 다음과 같은 단계를 거친다.

1. 생성 (Establishment): 클라이언트는 new WebTransport(url) 생성자를 호출하여 서버에 연결을 시도한다. 이때 URL은 반드시 https:// 스킴을 사용해야 하며, 포트 번호를 명시적으로 지정해야 한다. 이는 WebTransport가 보안 연결(TLS)을 강제함을 의미한다.9

2. 준비 (Ready): 연결 시도가 성공적으로 완료되면, transport.ready 프로미스(Promise)가 이행(fulfill)된다. 이 시점부터 스트림을 생성하거나 데이터그램을 전송할 수 있다.6 만약 서버가 클라이언트의 요청을 거부하는 등 연결에 실패하면

transport.closed 프로미스가 거부(reject)된다.6

3. 종료 (Termination): 클라이언트는 transport.close() 메서드를 호출하여 세션을 정상적으로 종료할 수 있다. 또는 서버 측의 요청이나 네트워크 오류로 인해 연결이 예기치 않게 종료될 수도 있다. 어떤 경우든 연결이 종료되면 transport.closed 프로미스가 이행되며, 이 프로미스는 종료 원인에 대한 정보를 담은 객체를 제공한다.6

3.4 표 1: 주요 브라우저별 WebTransport API 지원 현황

WebTransport는 클라이언트(브라우저)와 서버 간의 통신 기술이므로, C++로 서버를 구현하더라도 클라이언트 측의 지원 여부가 기술 채택의 핵심 전제 조건이 된다. 다음 표는 주요 브라우저의 WebTransport API 지원 현황을 요약한 것이다.

자료 종합: 19

이 표는 C++ 서버 개발자가 타겟 클라이언트 환경을 고려하여 기술 도입의 현실성을 판단하는 데 중요한 기준을 제공한다. 2024년 현재, Chromium 계열 브라우저와 Firefox에서는 안정적으로 사용 가능하지만, Safari의 지원이 아직 실험 단계에 머물러 있어 iOS 및 macOS 사용자를 대상으로 하는 서비스에서는 폴백(fallback) 전략이 필요할 수 있다.

4. 기존 실시간 통신 기술과의 비교 분석

WebTransport의 진정한 가치는 기존 기술인 WebSocket 및 WebRTC 데이터 채널과의 비교를 통해 명확해진다. 각 기술은 서로 다른 설계 철학과 아키텍처를 가지며, 이는 성능, 복잡성, 그리고 적합한 활용 사례에 결정적인 차이를 만들어낸다.

4.1 WebTransport vs. WebSocket

WebTransport는 종종 “WebSocket의 진화된 버전” 또는 “차세대 WebSocket“으로 불리지만, 이는 단순한 기능 개선을 넘어선 근본적인 프로토콜 스택의 차이에서 비롯된다.

• 프로토콜 스택 및 HOL 블로킹: WebTransport는 UDP/QUIC/HTTP/3 스택 위에서 동작하여 전송 계층 수준에서 다중 스트림을 지원하고 HOL 블로킹 문제를 원천적으로 해결한다.3 반면, WebSocket은 TCP 위에서 동작하므로, HTTP/1.1 연결을 업그레이드하는 방식을 사용한다. 이로 인해 TCP 계층의 HOL 블로킹에 필연적으로 노출된다.2
• 전송 모드 및 유연성: WebTransport의 가장 큰 장점은 신뢰성 있는 스트림과 비신뢰성 데이터그램이라는 두 가지 전송 모드를 단일 연결 내에서 동시에 제공한다는 점이다.6 개발자는 데이터의 특성에 따라 최적의 전송 방식을 선택할 수 있다. WebSocket은 기본적으로 신뢰성 있는 단일 메시지 스트림만을 제공하므로 이러한 유연성이 부족하다.4
• 연결 오버헤드: WebTransport는 QUIC의 1-RTT (또는 0-RTT) 핸드셰이크 덕분에 연결 설정이 매우 빠르며, 다수의 스트림을 생성하고 닫는 데 드는 비용이 매우 낮다.6 WebSocket은 TCP 3-way 핸드셰이크, TLS 핸드셰이크, 그리고 HTTP Upgrade 요청 및 응답 과정을 거치므로 상대적으로 연결 설정 오버헤드가 크다.5

4.2 WebTransport vs. WebRTC 데이터 채널

WebTransport와 WebRTC 데이터 채널은 모두 저지연, 비신뢰성 데이터 전송이 가능하다는 공통점이 있지만, 그들의 설계 목표와 아키텍처는 근본적으로 다르다.

• 아키텍처: WebTransport는 명확하게 클라이언트-서버 모델을 위해 설계되었다.6 모든 통신은 중앙 서버를 경유한다. 반면, WebRTC는 본질적으로 P2P(Peer-to-Peer) 통신을 목표로 하며, 브라우저 간의 직접적인 연결을 지향한다.5
• 연결 설정 복잡도: WebTransport는 표준 HTTP/3 서버에 연결하는 방식이므로 서버 설정이 비교적 간단하다. 개발자는 HTTP/3를 지원하는 서버만 준비하면 된다.6 반면, WebRTC는 P2P 연결을 성사시키기 위해 별도의 시그널링 서버가 필요하며, 클라이언트들이 서로 다른 네트워크 환경(NAT, 방화벽)에 있더라도 연결 경로를 찾기 위해 ICE, STUN, TURN과 같은 복잡한 프로토콜 스택을 이해하고 구현해야 한다. 이는 서버 구축 및 운영의 복잡도를 기하급수적으로 높인다.5
• API 설계 및 개발자 경험: WebTransport API는 최신 웹 플랫폼 표준인 Streams API, Promise, async/await와 자연스럽게 통합되어 있어 현대적인 웹 개발자에게 매우 친숙하고 직관적이다.6 또한 웹 워커(Web Worker) 내에서도 지원되어 백그라운드 통신이 가능하다.6 WebRTC API는 더 많은 구성 요소와 상태 관리를 요구하며, 그 복잡성으로 인해 학습 곡선이 가파르다.13

4.3 표 2: WebTransport, WebSocket, WebRTC 데이터 채널 비교 분석

세 가지 기술의 특성을 종합적으로 비교하면 다음과 같다. 이 표는 개발자가 자신의 애플리케이션 요구사항에 가장 적합한 기술을 전략적으로 선택하는 데 도움을 줄 수 있다.

자료 종합: 3

4.4 기술 포지셔닝 및 대체 가능성: WebTransport + WebCodecs 패러다임

WebTransport의 등장은 단순히 기존 기술을 대체하는 것을 넘어, 실시간 미디어 애플리케이션 아키텍처에 근본적인 패러다임 전환을 제시한다. 특히 WebCodecs API와의 결합은 WebRTC의 한계를 극복할 강력한 대안을 만들어낸다.

WebRTC의 가장 큰 특징은 미디어 파이프라인(캡처, 인코딩, 전송, 디코딩, 렌더링)이 하나의 거대한 ’블랙박스’처럼 강하게 결합되어 있다는 점이다.13 이는 일반적인 화상회의 애플리케이션을 쉽게 만들 수 있다는 장점이 있지만, 개발자가 파이프라인의 각 단계를 세밀하게 제어하거나 커스터마이징하기는 매우 어렵다는 단점을 낳는다. 예를 들어, 방송 서비스인 Twitch가 WebRTC를 저지연 스트리밍에 도입하려 했을 때, WebRTC가 품질보다 지연 시간 감소를 우선하도록 하드코딩되어 있어 방송 품질이 저하되는 문제를 겪었다.13

WebTransport와 WebCodecs의 조합은 이 ‘일체형’ 블랙박스 모델을 ‘모듈형’ 모델로 분해하여 개발자에게 완전한 제어권을 돌려준다.

1. WebCodecs API는 개발자가 브라우저에서 미디어 프레임의 인코딩과 디코딩 과정을 직접 제어할 수 있게 한다.13 개발자는 원시 비디오 프레임을 입력으로 받아 인코딩된 프레임을 출력하고, 그 반대의 과정도 수행할 수 있다.
2. WebTransport API는 이렇게 인코딩된 프레임을 네트워크를 통해 어떻게 전송할지를 결정하는 역할을 맡는다.13 예를 들어, 비디오의 핵심 프레임(I-frame)은 신뢰성 있는 스트림으로 전송하고, 예측 프레임(P/B-frame)은 손실이 허용되는 비신뢰성 데이터그램으로 전송하는 등 정교한 전송 전략을 구현할 수 있다.

이러한 분리는 개발자가 애플리케이션의 특성에 맞춰 미디어 처리와 전송 로직을 독립적으로 최적화할 수 있음을 의미한다. 이는 단순한 기술 대체를 넘어, 웹 기반 실시간 미디어 애플리케이션의 아키텍처 설계에 대한 근본적인 사고방식의 전환을 요구한다. C++로 작성되는 서버는 이제 클라이언트로부터 원시 미디어 스트림이 아닌, WebCodecs를 통해 정교하게 제어되고 인코딩된 프레임 덩어리(chunk)들을 수신하게 된다. 따라서 서버 측의 미디어 파싱, 처리, 재조합 로직 또한 이 새로운 패러다임에 맞춰 설계되어야 한다.

5. C++에서의 WebTransport 구현 전략

WebTransport의 기술적 우수성에도 불구하고, C++ 개발자가 이를 실제 프로덕션 환경에 도입하는 데에는 상당한 장벽이 존재한다. 가장 큰 문제는 성숙하고 안정적인 C++ 라이브러리 생태계가 아직 형성되지 않았다는 점이다.

5.1 C++ 생태계 현황 분석

Go (webtransport-go), Rust (webtransport-rs, h3)와 같은 최신 언어들은 커뮤니티 주도로 발 빠르게 WebTransport 구현체를 내놓고 있는 반면, C++ 생태계는 상대적으로 더딘 움직임을 보이고 있다.29

WebTransport를 구현하기 위해서는 완전한 QUIC 및 HTTP/3 프로토콜 스택이 필요한데, 이는 C++로 처음부터 개발하기에 엄청나게 방대하고 복잡한 작업이다. 따라서 대부분의 C/C++ 구현 시도는 Chromium의 libquic 12, Microsoft의 MsQuic 32, Cloudflare의 quiche 등 기존에 검증된 QUIC 구현에 의존하는 형태를 띤다. 하지만 이들 QUIC 라이브러리조차도 독립적인 사용을 염두에 두고 설계되지 않은 경우가 많아, 특정 프로젝트에서 분리하여 사용하는 데 많은 노력이 필요하다.

5.2 표 3: C/C++ QUIC 및 WebTransport 라이브러리 생태계 분석

현재 C++ 개발자가 고려할 수 있는 주요 라이브러리들의 현황은 다음과 같다. 이 표는 각 라이브러리의 상태와 특성을 비교하여 현실적인 기술 선택을 돕기 위해 작성되었다.

자료 종합: 30

이 표는 C++ 환경에서 “즉시 사용 가능한(out-of-the-box)” 프로덕션급 WebTransport 라이브러리가 사실상 부재함을 명확히 보여준다. libwtf는 유망하지만 아직 초기 단계이고, owt-sdk-quic은 단종되어 더 이상 사용할 수 없다. 따라서 C++ 개발자는 기존 QUIC 라이브러리를 활용하여 WebTransport 계층을 직접 구현하거나, C 라이브러리를 래핑하는 전략을 고려해야 한다.

5.3 사례 연구 1: libwtf (C 라이브러리) 활용 전략

libwtf는 Microsoft의 고성능 QUIC 구현체인 MsQuic 위에 구축된 C 언어 WebTransport 라이브러리다.32 아직 초기 개발 단계이지만, C++ 프로젝트에서 활용할 수 있는 현실적인 방안 중 하나다.

• 아키텍처 및 API: libwtf는 콜백(callback) 기반의 비동기 API를 제공한다. 개발자는 wtf_session_callback과 wtf_stream_callback 같은 함수를 등록하여 WTF_SESSION_EVENT_STREAM_OPENED, WTF_STREAM_EVENT_DATA_RECEIVED와 같은 이벤트를 처리하는 방식으로 동작한다.32
• C++ 래퍼(Wrapper) 구현 전략: C 라이브러리를 현대적인 C++에서 안전하고 편리하게 사용하기 위해 래퍼를 구현하는 것이 권장된다.

1. RAII(Resource Acquisition Is Initialization): wtf_context_t*, wtf_session_t*와 같은 C 스타일 핸들을 C++ 클래스로 감싼다. 생성자에서 리소스를 획득하고(wtf_context_create), 소멸자에서 리소스를 해제(wtf_context_destroy)하여 메모리 누수를 방지한다.
2. 콜백 추상화: C API의 void* user_data 포인터와 함수 포인터 조합을 std::function과 람다(lambda) 캡처를 사용하여 대체한다. 이를 통해 콜백 함수 내에서 클래스 멤버 변수나 다른 상태에 안전하게 접근할 수 있다.
3. 오류 처리: wtf_result_t와 같은 C 스타일 오류 코드를 C++ 예외(exception) 처리 메커니즘으로 변환하여 오류 처리를 일관성 있게 만든다.

이러한 래핑 전략을 통해 C 라이브러리의 저수준 세부 사항을 숨기고, C++ 개발자에게 더 익숙하고 안전한 인터페이스를 제공할 수 있다.

5.4 사례 연구 2: owt-sdk-quic (단종된 C++ SDK) 분석

Intel이 주도하여 개발했던 owt-sdk-quic은 Chromium 프로젝트의 QUIC 코드를 기반으로 한 C++ WebTransport SDK였다.33 비록 현재는 유지보수가 중단되었지만 33, 이 프로젝트의 실패는 C++ 생태계에 중요한 교훈을 남긴다.

이는 ’거인의 어깨 위에 서는 것’에 따르는 비용과 위험을 명확히 보여주는 사례다. Chromium의 QUIC 코드는 세계에서 가장 많이 테스트되고 기능이 풍부한 구현체 중 하나이지만, 동시에 독립적인 라이브러리로 사용되도록 설계되지 않았다.12 Chromium 내 수많은 모듈과 강하게 결합되어 있으며, 개발 속도가 매우 빨라 API가 수시로 변경된다.

owt-sdk-quic과 같은 외부 프로젝트는 이러한 변화를 지속적으로 추적하고, 자신들의 코드베이스에 변경 사항을 반영하며, 기존에 적용했던 패치들을 새로운 버전에 맞게 다시 적용하는 고통스러운 과정을 반복해야 한다. libquic 리포지토리의 동기화 스크립트(sync.py)와 그 설명은 이 과정이 얼마나 복잡하고 노동 집약적인지를 암시한다.12 결국 이러한 막대한 유지보수 비용을 감당할 핵심 개발팀의 지원이 끊기면서 프로젝트는 도태된 것으로 추정된다.

이 사례는 C++로 WebTransport를 구현하려는 개발자에게 중요한 시사점을 준다. 단순히 기능이 풍부한 코드를 가져오는 것만으로는 충분하지 않으며, ’지속 가능한 유지보수 전략’이 부재한 프로젝트는 장기적으로 실패할 수밖에 없다. 라이브러리를 선택하거나 직접 구현을 고려할 때, 현재의 기능뿐만 아니라 커뮤니티의 활성도, 상위 프로젝트(upstream)와의 관계, 그리고 장기적인 유지보수 계획을 반드시 평가해야 한다.

5.5 QUIC 라이브러리 기반 직접 구현 접근법

가장 안정적이고 통제 가능한 방법은 Facebook의 mvfst 34나 Cloudflare의 quiche (C API 제공) 30와 같이 활발하게 유지보수되는 고성능 C++ QUIC 라이브러리를 기반으로, IETF 표준 16에 명시된 WebTransport-over-HTTP/3 계층을 직접 구현하는 것이다. 이는 상당한 초기 개발 비용을 요구하지만, 기술을 완전히 내재화하고 특정 요구사항에 맞게 최적화할 수 있다는 장점이 있다.

구현해야 할 핵심 과제는 다음과 같다.

1. HTTP/3 CONNECT 핸들러: 수신되는 HTTP/3 CONNECT 요청을 가로채, sec-webtransport-http3-draft02와 같은 헤더를 파싱하여 WebTransport 세션 요청인지 확인하고 협상하는 로직을 구현한다.
2. 세션 관리: 성공적으로 협상된 각 연결에 대해 고유한 WebTransport 세션 객체를 생성하고 세션 ID를 할당하여 관리한다.
3. 스트림 디멀티플렉서: QUIC 계층으로부터 새로운 스트림이 생성되었다는 이벤트를 받으면, 스트림의 첫 바이트들을 읽어 스트림 타입(0x41 또는 0x54)과 세션 ID를 파싱한다. 이 정보를 바탕으로 해당 스트림을 올바른 세션 객체의 핸들러로 라우팅하는 디멀티플렉서를 구현해야 한다.
4. 데이터그램 처리: QUIC 라이브러리가 제공하는 데이터그램 수신 API를 통해 들어온 데이터그램을 파싱하고, 세션 ID를 추출하여 적절한 세션으로 전달한다.
5. 고수준 C++ API 설계: 저수준 프로토콜 처리를 추상화하고, W3C Web API와 유사한 개념(예: Session, BidirectionalStream, Datagrams)을 제공하는 사용자 친화적인 C++ 인터페이스를 설계한다.

5.6 C++ 서버 구현 코드 예시 (개념 증명)

다음은 4.4에서 논의된 직접 구현 접근법을 바탕으로 한 아키텍처 수준의 가상 C++ 코드이다. 이는 실제 동작하는 코드가 아니며, 전체적인 구조와 클래스 간의 상호작용을 보여주기 위한 개념 증명(Proof-of-Concept)이다.

// 가상 코드: 실제 컴파일되지 않음. 아키텍처 개념 설명용.
#include <iostream>
#include <memory>
#include <string>
#include <vector>
#include <functional>

// --- 가상의 QUIC 라이브러리 인터페이스 ---
namespace quic_lib {
class Connection; // QUIC 연결
class Stream;     // QUIC 스트림
}

// --- WebTransport 인터페이스 ---
class WebTransportStream {
public:
virtual ~WebTransportStream() = default;
void Write(const std::vector<uint8_t>& data);
void SetOnReadCallback(std::function<void(const std::vector<uint8_t>&)> cb);
void Close();
};

class WebTransportSession {
public:
explicit WebTransportSession(uint64_t session_id) : id_(session_id) {}
virtual ~WebTransportSession() = default;

void SendDatagram(const std::vector<uint8_t>& data);
std::shared_ptr<WebTransportStream> CreateBidirectionalStream();

// 이벤트 핸들러 설정
void SetOnStreamCallback(std::function<void(std::shared_ptr<WebTransportStream>)> cb);
void SetOnDatagramCallback(std::function<void(const std::vector<uint8_t>&)> cb);
void SetOnCloseCallback(std::function<void(const std::string&)> cb);

private:
uint64_t id_;
// 내부적으로 QUIC 스트림 및 데이터그램 처리 로직 포함
};

class WebTransportServer {
public:
WebTransportServer(const std::string& host, int port);
void Start();
void Stop();

// 새로운 세션이 생성될 때 호출될 콜백 설정
void SetOnSessionCallback(std::function<void(std::shared_ptr<WebTransportSession>)> cb);

private:
// 내부적으로 QUIC 서버 및 HTTP/3 핸들러 포함
void OnQuicConnection(std::shared_ptr<quic_lib::Connection> conn);
void OnHttp3ConnectRequest(std::shared_ptr<quic_lib::Stream> stream);
void OnQuicStream(std::shared_ptr<quic_lib::Stream> stream);
void OnQuicDatagram(const std::vector<uint8_t>& datagram);

std::function<void(std::shared_ptr<WebTransportSession>)> on_session_cb_;
// 세션 ID와 세션 객체를 매핑하는 맵
// std::map<uint64_t, std::shared_ptr<WebTransportSession>> sessions_;
};

// --- 애플리케이션 로직 ---
int main() {
WebTransportServer server("0.0.0.0", 4433);

server.SetOnSessionCallback((std::shared_ptr<WebTransportSession> session) {
std::cout << "New WebTransport session created!" << std::endl;

session->SetOnDatagramCallback((const std::vector<uint8_t>& data) {
std::cout << "Datagram received: " << std::string(data.begin(), data.end()) << std::endl;
// 에코(Echo) 로직
// session->SendDatagram(data);
});

session->SetOnStreamCallback((std::shared_ptr<WebTransportStream> stream) {
std::cout << "New stream opened by client!" << std::endl;
stream->SetOnReadCallback([stream](const%20std::vector<uint8_t>&%20data) {
std::cout << "Stream data received: " << std::string(data.begin(), data.end()) << std::endl;
// 에코(Echo) 로직
// stream->Write(data);
});
});
});

server.Start();
//... 서버 실행 루프...
server.Stop();

return 0;
}

6. 주요 활용 사례 및 성능 고려사항

WebTransport의 유연한 통신 모델은 다양한 실시간 애플리케이션에 새로운 가능성을 제시한다. 특히 저지연과 높은 처리량이 동시에 요구되는 시나리오에서 그 진가를 발휘한다.

6.1 실시간 게임

온라인 멀티플레이어 게임은 WebTransport의 기능을 가장 잘 활용할 수 있는 대표적인 분야다.

• 요구사항: 플레이어의 입력이나 위치 데이터와 같이 시간에 매우 민감한 정보는 일부가 유실되더라도 가장 최신 정보가 빠르게 전달되는 것이 중요하다. 반면, 채팅 메시지나 아이템 획득과 같은 중요한 상태 정보는 반드시 신뢰성 있게 전달되어야 한다.28
• 적용: 비신뢰성 데이터그램 API를 사용하여 플레이어의 위치, 방향, 액션과 같은 고주파수 상태 정보를 최소한의 지연으로 서버와 동기화한다.6 데이터그램은 순서나 전송이 보장되지 않지만, 게임 로직에서는 항상 최신 정보만 사용하면 되므로 문제가 되지 않는다. 동시에, 신뢰성 있는 스트림을 사용하여 채팅 메시지, 게임 시작/종료 이벤트, 중요한 상태 변경 등을 안정적으로 전달할 수 있다.37 클라우드 게이밍 환경에서는 서버에서 렌더링된 비디오 화면을 저지연 스트림으로 클라이언트에 전송하고, 클라이언트의 키보드/마우스 입력은 데이터그램으로 서버에 즉시 전송하는 하이브리드 모델을 구현할 수 있다.28

6.2 저지연 라이브 스트리밍

스포츠 중계, 온라인 경매, 원격 수술, 서버 기반 화상 회의 등 1초 미만의 지연 시간이 중요한 라이브 스트리밍 서비스에서 WebTransport는 탁월한 성능을 제공한다.

• 요구사항: 시청자와의 상호작용을 위해 지연 시간을 최소화해야 하며, 비디오, 오디오, 데이터(예: 자막, 투표 정보) 등 여러 미디어 트랙을 동기화하여 안정적으로 전송해야 한다.28
• 적용: WebTransport의 다중 스트림 기능을 활용하여 비디오, 오디오, 데이터를 각각 독립적인 단방향 스트림으로 전송할 수 있다.18 이렇게 하면 특정 미디어 트랙(예: 고화질 비디오)에서 패킷 손실이 발생하더라도 다른 트랙(예: 오디오)에 영향을 주지 않아 전체적인 스트리밍 경험의 안정성을 높일 수 있다. 데이터그램은 타임스탬프나 동기화 메타데이터를 전송하여 여러 스트림 간의 동기화를 맞추는 데 사용될 수 있다.28

6.3 IoT 및 센서 데이터 전송

수많은 사물인터넷(IoT) 장치로부터 데이터를 수집하고 분석하는 시나리오에서도 WebTransport는 효율적인 솔루션을 제공한다.

• 요구사항: 저전력, 저사양의 장치에서 간헐적으로 발생하는 작은 크기의 센서 데이터를 최소한의 오버헤드로 중앙 서버에 전송해야 한다. 장치의 배터리 수명을 고려하여 불필요한 네트워크 통신을 줄이는 것이 중요하다.28
• 적용: QUIC의 0-RTT 연결 재개 기능을 활용하면, 장치가 슬립 모드에서 깨어날 때마다 매우 빠르게 서버와 연결을 다시 수립하고 데이터를 전송할 수 있다. GPS 위치 업데이트, 온도/습도 값 등 작은 크기의 데이터는 데이터그램으로 전송하여 오버헤드를 최소화한다. 이는 수백만 개의 IoT 장치가 네트워크에 과도한 부하를 주지 않으면서도 실시간으로 데이터를 전송할 수 있게 해준다.37

6.4 성능 벤치마크 분석

다양한 연구 및 실험 결과는 특정 조건 하에서 WebTransport의 성능적 우위를 입증한다.

• 패킷 손실 환경에서의 강점: 한 연구에 따르면, 인위적으로 패킷 손실을 유발한 불안정한 네트워크 환경에서 WebTransport(신뢰성 스트림)는 TCP 기반의 WebSocket보다 훨씬 낮은 RTT(Round-Trip Time)를 기록하며 뛰어난 성능을 보였다.2 이는 QUIC의 빠른 손실 감지 및 복구 메커니즘 덕분이다.

• 데이터그램의 우수한 지연 시간: Go 언어로 구현된 라이브러리를 사용한 실험에서, WebTransport 데이터그램은 신뢰성 있는 스트림보다 지속적으로 낮은 지연 시간을 보였다. 특히 15%의 패킷 손실 환경에서는 WebRTC 데이터 채널보다 더 많은 메시지를 성공적으로 전달하는 경향을 나타냈다.39 이는 WebTransport의 혼잡 제어 메커니즘이 WebRTC의 SCTP 기반 구현보다 더 효율적으로 동작할 수 있음을 시사한다.

• 구현 성숙도에 따른 성능 편차: 일부 초기 벤치마크에서는 WebTransport 구현이 예상보다 저조한 성능을 보이는 경우도 보고되었다.2 이는 라이브러리의 최적화 수준이나 테스트 환경 설정(예: 운영체제의 UDP 수신 버퍼 크기)에 따라 성능이 크게 달라질 수 있음을 의미한다.39 특히 C++로 서버를 구현할 때는

sendmmsg/recvmmsg와 같은 시스템 콜을 효율적으로 사용하여 시스템 콜 오버헤드를 줄이는 것이 성능에 결정적인 영향을 미칠 수 있다.40

7. 결론 및 제언

WebTransport는 QUIC과 HTTP/3의 강력한 성능을 웹 애플리케이션으로 가져오는 혁신적인 프로토콜 프레임워크다. HOL 블로킹 해결, 저지연 연결, 그리고 신뢰성 있는 스트림과 비신뢰성 데이터그램을 모두 지원하는 유연성을 통해 기존 실시간 통신 기술의 한계를 명확히 극복한다. 이론적으로 WebTransport는 C++로 고성능, 고확장성 실시간 서버를 구축하기 위한 이상적인 기술이다.

그러나 C++ 개발자가 마주한 현실은 녹록지 않다. 프로토콜의 기술적 우위와 C++ 생태계의 성숙도 사이에는 상당한 격차가 존재한다. 2024년 현재, 프로덕션 환경에 즉시 적용할 수 있을 만큼 안정적이고 활발하게 유지보수되는 C++ WebTransport 라이브러리는 사실상 부재한 상황이다. 또한, 웹 기반 C++ 개발의 핵심 도구인 Emscripten에서 WebTransport를 공식적으로 지원하지 않는다는 점은 웹 타겟 애플리케이션 개발에 또 다른 장벽으로 작용한다.41

이러한 현실을 고려하여, C++ 개발자는 다음과 같은 단계적이고 전략적인 접근법을 취할 것을 제언한다.

• 단기적/실험적 접근: 프로젝트가 특정 플랫폼(예: Windows)을 타겟으로 하거나, 프로토타입 개발이 목표라면 libwtf와 같은 C 라이브러리를 C++로 안전하게 래핑하여 사용하는 것을 고려할 수 있다. 이 접근법은 WebTransport의 개념을 빠르게 검증하고 학습하는 데 유용하지만, 라이브러리의 초기 개발 단계에 따른 불안정성과 플랫폼 종속성 문제를 감수해야 한다.
• 장기적/전략적 접근: 애플리케이션의 핵심 비즈니스 로직이 저지연 실시간 통신에 깊이 의존하고, 장기적인 안정성과 확장성이 중요하다면, 보다 근본적인 해결책을 모색해야 한다. Facebook의 mvfst나 Cloudflare의 quiche와 같이 검증되고 활발하게 유지보수되는 QUIC 라이브러리를 기반으로, WebTransport 프로토콜 계층을 직접 구현하는 것을 장기적인 로드맵으로 수립하는 것이 바람직하다. 이 방법은 상당한 초기 투자 비용과 높은 수준의 기술력을 요구하지만, 기술을 완벽하게 내재화하고 특정 요구사항에 맞게 최적화하며, 외부 종속성에서 벗어날 수 있다는 결정적인 이점을 제공한다.

마지막으로, C++ 생태계 전체의 발전을 위한 제언을 덧붙인다. C++가 Go, Rust와 같은 현대 시스템 프로그래밍 언어와의 경쟁에서 고성능 네트워크 분야의 리더십을 유지하기 위해서는, 커뮤니티와 표준 위원회의 적극적인 노력이 필요하다. Boost.Asio나 C++23 네트워킹 라이브러리(Networking TS)와 같은 표준 프레임워크 내에서 QUIC 및 WebTransport를 지원하는 방안을 공식적으로 논의하고 추진해야 한다. 이는 개별 개발자나 기업의 노력을 넘어, C++ 언어 자체의 경쟁력을 강화하고 미래의 웹 기술 변화에 능동적으로 대응하기 위한 필수적인 과제일 것이다.

8. 참고 자료

1. What is WebTransport and How Does it Work? - PubNub, https://www.pubnub.com/guides/webtransport/
2. EMPIRICAL ANALYSIS OF THE IMPACT OF PACKET LOSS ON WEBTRANSPORT USING SOCKET.IO - DiVA portal, http://www.diva-portal.org/smash/get/diva2:1876796/FULLTEXT01.pdf
3. WebTransport Protocol - Medium, https://medium.com/@shubhijain/webtransport-protocol-3d0169dc3b56
4. The WebSocket API (WebSockets) - Web APIs - MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
5. WebSocket vs WebRTC DataChannel: Choosing the Right Real-Time Tech - VideoSDK, https://www.videosdk.live/developer-hub/webrtc/websocket-vs-webrtc-datachannel
6. Using WebTransport | Capabilities - Chrome for Developers, https://developer.chrome.com/docs/capabilities/web-apis/webtransport
7. WebRTC vs WebTransport: Comparison Guide - VideoSDK, https://www.videosdk.live/developer-hub/webtransport/webrtc-vs-webtransport
8. draft-ietf-webtrans-http3-13 - WebTransport over HTTP/3, https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/
9. WebTransport API - MDN Web Docs - Mozilla, https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API
10. HTTP/3 - Wikipedia, https://en.wikipedia.org/wiki/HTTP/3
11. WebTransport is a proposed API to expose QUIC’s datagrams and streams to JavaScript clients : r/programming - Reddit, https://www.reddit.com/r/programming/comments/oeg6oc/webtransport_is_a_proposed_api_to_expose_quics/
12. devsisters/libquic: QUIC, a multiplexed stream transport over UDP - GitHub, https://github.com/devsisters/libquic
13. Replacing WebRTC - Media over QUIC, https://quic.video/blog/replacing-webrtc/
14. Enabling HTTP/3 for Fastly services | Fastly Documentation, https://www.fastly.com/documentation/guides/full-site-delivery/performance/enabling-http3-for-fastly-services/
15. RFC 9114: HTTP/3, https://www.rfc-editor.org/rfc/rfc9114.html
16. draft-ietf-webtrans-http3-13 - IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3
17. draft-ietf-webtrans-overview-10 - The WebTransport Protocol Framework, https://datatracker.ietf.org/doc/draft-ietf-webtrans-overview/
18. TPAC 2021: WebTransport Working Group Updates - W3C, https://www.w3.org/2021/10/TPAC/demos/webtransport.html
19. WebTransport - Web APIs - MDN Web Docs - Mozilla, https://developer.mozilla.org/en-US/docs/Web/API/WebTransport
20. The WebTransport Protocol Framework - IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview-07
21. WebTransport is a web API for flexible data transport - GitHub, https://github.com/w3c/webtransport
22. WebTransport: datagrams property - Web APIs | MDN, https://developer.mozilla.org/en-US/docs/Web/API/WebTransport/datagrams
23. WebTransport. What will drive next-generation… | by Poby’s Home - Medium, https://poby.medium.com/webtransport-472621795cf7
24. “webtransport” | Can I use… Support tables for HTML5, CSS3, etc - CanIUse, https://caniuse.com/?search=webtransport
25. WebTransport API | Can I use… Support tables for HTML5, CSS3, etc - CanIUse, https://caniuse.com/mdn-api_webtransport
26. WebRTC vs. WebSocket: Key differences and which to use - Ably, https://ably.com/topic/webrtc-vs-websocket
27. WebRTC API - MDN Web Docs - Mozilla, https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API
28. webtransport/use-cases.md at main - GitHub, https://github.com/w3c/webtransport/blob/main/use-cases.md
29. webtransport / GitHub Topics, https://github.com/topics/webtransport
30. Best performing quic implementation? : r/rust - Reddit, https://www.reddit.com/r/rust/comments/11jn4kw/best_performing_quic_implementation/
31. Replacing WebRTC: real-time latency with WebTransport and WebCodecs - Reddit, https://www.reddit.com/r/programming/comments/17juwdb/replacing_webrtc_realtime_latency_with/
32. andrewmd5/libwtf: A fast WebTransport implementation in C - GitHub, https://github.com/andrewmd5/libwtf
33. open-webrtc-toolkit/owt-sdk-quic: C++ server and client … - GitHub, https://github.com/open-webrtc-toolkit/owt-sdk-quic
34. facebook/mvfst: An implementation of the QUIC transport protocol. - GitHub, https://github.com/facebook/mvfst
35. yhirose/cpp-httplib: A C++ header-only HTTP/HTTPS server and client library - GitHub, https://github.com/yhirose/cpp-httplib
36. paullouisageneau/libdatachannel: C/C++ WebRTC network library featuring Data Channels, Media Transport, and WebSockets - GitHub, https://github.com/paullouisageneau/libdatachannel
37. What is WebTransport and can it replace WebSockets? - Ably, https://ably.com/blog/can-webtransport-replace-websockets
38. WebTransport: The Future of Real-Time Communication, Bridging the Gap Beyond WebRTC & Websockets | by Lakin Mohapatra, https://lakin-mohapatra.medium.com/web-transport-the-future-of-real-time-communication-bridging-the-gap-beyond-webrtc-e1203f284ae9
39. Sh3b0/realtime-web: Comparing WebSocket, WebRTC, and WebTransport under packet loss - GitHub, https://github.com/Sh3b0/realtime-web
40. C++ (or C, I guess) application server that’s QUIC/HTTP3 ready? : r/cpp - Reddit, https://www.reddit.com/r/cpp/comments/vngmeb/c_or_c_i_guess_application_server_thats_quichttp3/
41. [Feature Request] WebTransport (QUIC) API Support / Issue #21208 / emscripten-core … - GitHub, https://github.com/emscripten-core/emscripten/issues/21208
42. WebTransport | Can I use… Support tables for HTML5, CSS3, etc, https://caniuse.com/webtransport
43. C/C++ QUIC API Reference - TQUIC, https://tquic.net/docs/api_reference/c_quic/